Subject: [IPP] Proposal for mapping Printer MIB into IPP

From: Ira McDonald <[email-masked]>
Date: Sat, 21 Aug 2010 13:43:28 -0400

Hi,                                            Saturday (21 August 2010)

Per my action item from our August 2010 PWG Meeting, here is my proposal
for a new IPP spec called "IPP Printer Device Extensions".

Since the complete ABNF and mapping rules for all 170+ objects defined
in the Printer MIB will be fairly long, I suggest that this should be in
a separate IPP spec and not simply included in "IPP Everywhere" spec.

Comments?

Cheers,
- Ira

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

Approach:

- Avoid use of new Object (e.g., Device) or Collection to reduce cost
  for lightweight mobile implementations of IPP Clients

- Follow style of IPP PSX mapping of prtAlertTable, i.e., array of text
  parameters in "printer-alert" representing most columns and separate
  attributes like "printer-alert-description" for string MIB objects

- Convert all enumerated values from Printer MIB into IANA registered
  string names, e.g., "prtChannelType" of "38" maps to "chBidirPortTCP"

- Map bit masks, e.g., "prtChannelStatus (PrtSubUnitStatusTC), directly
  as integers (because string encoding in IPP is too verbose)

Pros:

- Simple human-readable text encoding

- Lightweight (no new attribute groups, objects, etc.)

- High fidelity mapping from Printer MIB objects to IPP attributes

Cons:

- Like "printer-alert", maps a *single* physical output device onto an
  IPP Printer object

- Note that this precedent was already established with "printer-alert"
  which has shipped in CUPS and various printers for several years

Examples:

printer-channel[1] =
    "index=1;type=chBidirPortTCP;jclIndex=0;pdlIndex=1;
    state=printDataAccepted;ifIndex=3;status=0;"

printer-channel-version[1] =
    "Bi-Directional Raw TCP/IP Printing"

printer-channel-info[1] =
    "Port=9100"

printer-marker[1] =
    "index=1;markTech=inkjetAqueous;counterUnit=impressions;
    lifeCount=23412;powerOnCount=479;processColorants=4;
    spotColorants=0;addressUnit=tenThousandthsOfInches;
    addressFeedDir=600;addressXFeedDir=600;
    northMargin=1066;southMargin=1066;eastMargin=1066;westMargin=1066;
    status=0;"

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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 23 Aug 2010 09:40:44 -0700

Comments inline...

> a separate IPP spec and not simply included in "IPP Everywhere" spec.

Of course we'll need to update the IPP charter to cover this, right? :)

> - Ira

I presume we would also require mapping of OID (indirect) values to the actual/real values?

>  which has shipped in CUPS and various printers for several years

- Puts a greater burden on the client to decode the "simple" human-readable text encoding.
- Does not expose "simple" attributes/values like we do for printer-state-reasons (e.g. printer-state-reasons gives the high-level issue, looking at printer-alert gives you details)

> Examples:

In the examples below you are including bracketed numbers after the name - what does that represent?

Also, the first 3 examples show how you would map a port 9100 print channel into an IPP attribute, which seems strange (something to think about for the "final" spec...)

>    northMargin=1066;southMargin=1066;eastMargin=1066;westMargin=1066;

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Mon, 23 Aug 2010 15:33:57 -0400

Hi Mike,

Square brackets in examples mean a row instance in 1setOf tables,
just like in IPP PSX examples.

On reflection, I agree that changing all the enums (dozens) to labels
is undesirable.  So I propose a high-fidelity direct mapping (i.e., an
integer object stays a decimal string integer and a string object gets
a separate IPP attribute, to disambiguate line delimiters).

Hmm?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434