Comments inline...
On Aug 21, 2010, at 10:43 AM, Ira McDonald wrote:
> 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?
Of course we'll need to update the IPP charter to cover this, right? :)
> 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)
I presume we would also require mapping of OID (indirect) values to the actual/real values?
>>> 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
- 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...)
> 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;"
________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.