Glen,
MediaInputTrayCheck and 5100.3's media-input-tray-check use the older Printer MIB naming convention, even though roll and slot names can be used.
MediaSource comes from JPS3's media-source - "source" as a more general word than "input tray" since it covers slots and rolls. We had a lot of discussion about this early in the definition of media-source for JPS3 and concluded that we should break the chain and use the new name. (oh, and realizing that we have printer-input-tray and printer-output-tray mapped from the MIB, I may propose to change those names accordingly for the final JPS3; "media-source" is widely implemented already but "printer-input-tray" and "printer-output-tray" are not...)
On Jan 24, 2012, at 2:58 PM, Petrie, Glen wrote:
> Pete, Mike
>> In the PJT the MediaInputTray is (I believe) is called MediaSource; so, at least in the PJT, should MediaInputTrayCheck become MediaSourceCheck??
>> Glen
>>> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Petrie, Glen
> Sent: Tuesday, January 24, 2012 2:34 PM
> To: Michael Sweet; Zehler, Peter
> Cc: ipp at pwg.org> Subject: RE: [IPP] media-input-tray-check-default
>> Should the value of “Unknown” be used? Below is the statement from rfc2911
>> Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP
> "out-of-band" value 'unknown'. See the description of the "out-of-
> band" values at the beginning of Section 4.1. Therefore, attributes
> of type 'enum' start at '3'.
>> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Michael Sweet
> Sent: Tuesday, January 24, 2012 8:53 AM
> To: Zehler, Peter
> Cc: ipp at pwg.org> Subject: Re: [IPP] media-input-tray-check-default
>> OK, I'm convinced. I'll add "no-value" to this one and any others like it where it would not always make sense to force a default value.
>>> On Jan 24, 2012, at 4:33 AM, Zehler, Peter wrote:
>>> Mike,
> I prefer option #2. One of my reason is that it allows the operator to set policy for underspecified jobs on the printer. (If the client is not being careful, then the printer will.) It is a very handy feature in production printing.
> Pete
>> Peter Zehler
>> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Paul Tykodi
> Sent: Tuesday, January 24, 2012 6:11 AM
> To: ipp at pwg.org> Subject: RE: [IPP] media-input-tray-check-default
>> Hi Mike,
>> For production printing, I have found during my career that it is critical to have automatic checks and balances within the job submission workflow so that a very large job (with a significant cost of production) is not released such that it will be printed on incorrect media and thus be a total loss (i.e. must be destroyed and cannot be distributed – job must be run again). The AFP Consortium has the same type of intelligence in their Intelligent Printer Data Stream specification as we have in IPP.
>> I think it is possible that some vendors may have interpreted the description in the specification to mean that the default value should refer to the function being enabled or disabled. If it is enabled, it then interacts with the media in the job ticket I therefore prefer option #2 to resolve this issue.
>> 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> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Michael Sweet
> Sent: Monday, January 23, 2012 6:14 PM
> To: ipp at pwg.org> Subject: [IPP] media-input-tray-check-default
>> All,
>> I am going through yet another round of updates to the IANA registry (this time for sure! :), and noticed that I still have the media-input-tray-check-default attribute tagged as "under review". I would like to resolve this before we submit our next round of updates to the registry.
>> BACKGROUND
>> PWG 5100.3 (Production Printing Set 1) defines the media-input-tray-check Job Template attribute thusly:
>> The “media-input-tray-check” Job Template attribute indicates that the Printer MUST check that the characteristics of the media in the identified input tray are the same as characteristics of the media identified by the Job's "media" Job Template attribute or matched (see section 3.13) by the Job's "media- col" Job Template attribute. The keyword values are the same input tray keyword values as are defined for the "media" Job Template attribute (see section 6.3 in this document and [RFC2911] Appendix C), i.e., 'top', 'middle', 'bottom', etc.
>> Independent of the "ipp-attributes-fidelity" operation attribute supplied by the client, if the characteristics differ, the Printer adds the ‘resources-are-not-ready’ value (see section 6.1) to the job's "job-state-reasons" attribute and MAY either (1) put the job into the ‘pending-held’ state or (2) start to process the job normally, but immediately stop the job (“job-state” = ‘processing-stopped’) and the Printer (“printer-state” = ‘stopped’). In either implementation, the operator can change the media in the input tray to agree with the job or can modify the job’s “media” or “media-col” attributes to agree with the input tray, depending on policy.
>> Table 1 (at the beginning of section 3) defines media-input-tray-check-default and -supported.
>> The issue is that there should not be a default media-input-tray-check value; like some other Job Template attributes (e.g. overrides), it does not make sense to have a default value for this particular attribute since it interacts with the media in the job ticket.
>> There are two ways to resolve this issue:
>> 1. Drop media-input-tray-check-default from the registry and post an errata for 5100.3 removing the media-input-tray-check-default attribute from Table 1.
>> 2. Update the definition of media-input-tray-check-default to include the "no-value" out-of-band value.
>> I prefer option #1.
>> Comments?
>> ________________________________________________________________________
> 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.
>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean. _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>> __________________________________________________
> 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.
>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
__________________________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20120124/c67aa74b/attachment-0002.html>