Subject: [IPP] media-input-tray-check-default

From: Michael Sweet <[email-masked]>
Date: Mon, 23 Jan 2012 15:13:35 -0800

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.

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

---

From: "Paul Tykodi" <[email-masked]>
Date: Tue, 24 Jan 2012 06:10:34 -0500

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:  [email-masked]
WWW:   <http://www.tykodi.com/> http://www.tykodi.com

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
Sweet
Sent: Monday, January 23, 2012 6:14 PM
To: [email-masked]
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.

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?

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean.

---

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 24 Jan 2012 04:33:47 -0800

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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Tykodi
Sent: Tuesday, January 24, 2012 6:11 AM
To: [email-masked]
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

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  [email-masked]
WWW:  http://www.tykodi.com <http://www.tykodi.com/> 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Sweet
Sent: Monday, January 23, 2012 6:14 PM
To: [email-masked]
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.

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.

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?

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 24 Jan 2012 08:52:52 -0800

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
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Tykodi
> 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
> WWW:  http://www.tykodi.com
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
> believed to be clean. _______________________________________________
> ipp mailing list
> [email-masked]

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Tue, 24 Jan 2012 12:45:07 -0500

Hi Mike,

Thanks - I agree w/ Pete about the advantages of
option 2 - and this is a more backward compatible
solution than actually deleting a previously registered
(and apparently implemented) IPP attribute.

The 'no-value' approach to special "xxx-default"
attributes is elegant.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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

On Tue, Jan 24, 2012 at 11:52 AM, Michael Sweet <[email-masked]> wrote:

> 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.
>
>
> Mike,****
> 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
>
> Webster NY, 14580-9701****
> ** **
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Paul
> Tykodi
> *Sent:* Tuesday, January 24, 2012 6:11 AM
> *To:* [email-masked]
> *Subject:* RE: [IPP] media-input-tray-check-default****
> ** **
> Hi Mike,****
> ** **
> 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.****
> ** **
> 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
> WWW:  http://www.tykodi.com****
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Michael
> Sweet
> *Sent:* Monday, January 23, 2012 6:14 PM
> *To:* [email-masked]
> *Subject:* [IPP] media-input-tray-check-default****
> ** **
> All,****
> ** **
> registry.****
> ** **
> BACKGROUND****
> ** **
> Job Template attribute thusly:****
> ** **
>
> The “media-input-tray-check” Job Template attribute indicates that the
> 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
> ‘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
> can modify the job’s “media” or “media-col” attributes to agree with the
> input tray, depending on policy.****
>
> ** **
> media-input-tray-check-default and -supported.****
> ** **
> 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:****
> ** **
> from Table 1.****
> ** **
> "no-value" out-of-band value.****
> ** **
> I prefer option #1.****
> ** **
> Comments?****
>  ****
> ________________________________________________________________________**
> **
> Michael Sweet, Senior Printing System Engineer, PWG Chair****
> ** **
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.****
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.****
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

---

From: "Petrie, Glen" <[email-masked]>
Date: Tue, 24 Jan 2012 14:33:39 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Sweet
Sent: Tuesday, January 24, 2012 8:53 AM
To: Zehler, Peter
Cc: [email-masked]
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.

Mike,

Pete

Peter Zehler

Xerox Research Center Webster
Email: [email-masked] <mailto:[email-masked]> 
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: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Paul Tykodi
Sent: Tuesday, January 24, 2012 6:11 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: RE: [IPP] media-input-tray-check-default

Hi Mike,

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  [email-masked] <mailto:[email-masked]> 
WWW:  http://www.tykodi.com <http://www.tykodi.com/> 

From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] <mailto:%5bmailto:[email-masked]%5d>
On Behalf Of Michael Sweet
Sent: Monday, January 23, 2012 6:14 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: [IPP] media-input-tray-check-default

All,

BACKGROUND

I prefer option #1.

Comments?

believed to be clean.

believed to be clean.

believed to be clean. _______________________________________________
ipp mailing list
[email-masked] <mailto:[email-masked]> 
https://www.pwg.org/mailman/listinfo/ipp
<https://www.pwg.org/mailman/listinfo/ipp> 

believed to be clean.

---

From: "Petrie, Glen" <[email-masked]>
Date: Tue, 24 Jan 2012 14:58:12 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Petrie, Glen
Sent: Tuesday, January 24, 2012 2:34 PM
To: Michael Sweet; Zehler, Peter
Cc: [email-masked]
Subject: RE: [IPP] media-input-tray-check-default

 

Mike,

Pete

Peter Zehler

Hi Mike,

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant

Tel/Fax: 603-343-1820
Mobile:  603-866-0712

All,

BACKGROUND

I prefer option #1.

Comments?

believed to be clean.

believed to be clean.

believed to be clean. 

believed to be clean.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 24 Jan 2012 15:49:54 -0800

Glen,

"unknown" is generally used for values that are produced by the printer/automata.

"no-value" is generally used for things that are configured by a human being.

For xxx-default attributes, "no-value" makes more sense than "unknown".

On Jan 24, 2012, at 2:33 PM, Petrie, Glen wrote:

> Should the value of “Unknown” be used?   Below is the statement from rfc2911
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 24 Jan 2012 15:56:40 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Petrie, Glen

---

From: "Petrie, Glen" <[email-masked]>
Date: Wed, 25 Jan 2012 05:58:34 -0800

Mike

I am ok with either name; but in PJT, if the convention is to use
MediaSource; then I believe we should use MediaSourceCheck and not
MediaInputTrayCheck.

From: Michael Sweet [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2012 3:57 PM
To: Petrie, Glen
Cc: Zehler, Peter; [email-masked]; [email-masked]
Subject: Re: [IPP] media-input-tray-check-default

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...)

Pete, Mike

Glen

 

Mike,

Pete

Peter Zehler

Hi Mike,

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant

Tel/Fax: 603-343-1820
Mobile:  603-866-0712

All,

BACKGROUND

I prefer option #1.

Comments?

believed to be clean.

believed to be clean.

believed to be clean. 

believed to be clean.

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 25 Jan 2012 06:57:08 -0800

Glen,

I want a cleaner mapping to IPP whenever possible.  I'd prefer
MediaInputTrayCheck with a clarifying clauses in the descriptions of
MediaSource and MediaInputTrayCheck.  

Pete

Peter Zehler

From: Petrie, Glen [mailto:[email-masked]] 
Sent: Wednesday, January 25, 2012 8:59 AM
To: Michael Sweet
Cc: Zehler, Peter; [email-masked]; [email-masked]
Subject: RE: [IPP] media-input-tray-check-default

Mike

Glen,

 

Pete, Mike

Glen

 

Mike,

Pete

Peter Zehler

Hi Mike,

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant

Tel/Fax: 603-343-1820
Mobile:  603-866-0712

All,

BACKGROUND

I prefer option #1.

Comments?

believed to be clean.

believed to be clean.

believed to be clean. 

believed to be clean.

---

From: "Petrie, Glen" <[email-masked]>
Date: Wed, 25 Jan 2012 07:12:12 -0800

Pete

Ok, but ....  people who will start using PJT and not real background
with or using IPP may find it confusing.  i.e. "Is it source?"  "Is it
tray?"  "Is it input tray?" "Are they the same thing?".   Does a client
display a label called "Media Source" or "Input Tray" or "Media Tray" or
"Media Input Tray".   One more push to use MediaSourceCheck and have a
note stating that new specifications have changed from Input Tray to
Media Source.

[If we change (input) tray to source; does output bin have a new name?]

Glen

From: Zehler, Peter [mailto:[email-masked]] 
Sent: Wednesday, January 25, 2012 6:57 AM
To: Petrie, Glen; Michael Sweet
Cc: [email-masked]; [email-masked]
Subject: RE: [IPP] media-input-tray-check-default

Glen,

Pete

Peter Zehler

Mike

<mailto:%5bmailto:[email-masked]%5d>  

Glen,

 

Pete, Mike

Glen

From: [email-masked] [mailto:[email-masked]]
<mailto:%5bmailto:[email-masked]%5d>  On Behalf Of Petrie, Glen
Sent: Tuesday, January 24, 2012 2:34 PM
To: Michael Sweet; Zehler, Peter
Cc: [email-masked]
Subject: RE: [IPP] media-input-tray-check-default

From: [email-masked] [mailto:[email-masked]]
<mailto:%5bmailto:[email-masked]%5d>  On Behalf Of Michael Sweet
Sent: Tuesday, January 24, 2012 8:53 AM
To: Zehler, Peter
Cc: [email-masked]
Subject: Re: [IPP] media-input-tray-check-default

 

Mike,

Pete

Peter Zehler

On Behalf Of Paul Tykodi

Hi Mike,

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant

Tel/Fax: 603-343-1820
Mobile:  603-866-0712

All,

BACKGROUND

I prefer option #1.

Comments?

believed to be clean.

believed to be clean.

believed to be clean. 

believed to be clean.

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 25 Jan 2012 08:12:50 -0800

Glen,

I really hate arguments over names of attributes/elements.  We are
talking about tags in a protocol.  We could change the attribute name
"media-input-tray-check" and the element name "MediaInputTrayCheck" to
"Appletree" and it would not change its semantics.  An application, used
by people,  can use any nomenclature deemed acceptable for the
environment.  A picture of a tray works just as well as any of the terms
you suggested below.  The objective of the model is not standardization
of user interfaces across the industry.  The goal is standardization
definitions of the semantics.  If the semantics contain a links between
"MediaSource", "MediaInputTrayCheck" and  "InputTray" then the Semantic
Model should clarify the relationship.  I would expect JPS3 to do the
same.

Note that the IPP and Semantic Model have mappings to the Printer MIB's
prtInputTable(1.3.6.1.2.1.43.8.2) and prtOutputTable
(1.3.6.1.2.1.43.9.2) subunits.  The Semantic Model represents the
complete subunits while IPP chose a subset of objects of interest.  The
Semantic Model choose the tags "InputTrays" and "OutputTrays" to map to
the MIB objects and documented those mappings in PWG5108.1.  There is no
direct mapping from IPP's representation of these MIB objects since the
Semantic Model maps its subunit elements (i.e., "Configuration"
elements) to the standard object definitions (i.e., RFC3805).

If you are seeking a standard name to put in a UI, perhaps a standard
message catalogue may be the answer.  It could also have standard names
in multiple languages.

Pete

Peter Zehler

From: Petrie, Glen [mailto:[email-masked]] 
Sent: Wednesday, January 25, 2012 10:12 AM
To: Zehler, Peter; Michael Sweet
Cc: [email-masked]; [email-masked]
Subject: RE: [IPP] media-input-tray-check-default

Pete

Glen

Glen,

Pete

Peter Zehler

Mike

Glen,

 

Pete, Mike

Glen

 

Mike,

Pete

Peter Zehler

Hi Mike,

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant

Tel/Fax: 603-343-1820
Mobile:  603-866-0712

All,

BACKGROUND

I prefer option #1.

Comments?

believed to be clean.

believed to be clean.

believed to be clean. 

believed to be clean.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 25 Jan 2012 08:16:25 -0800

Glen,

On Jan 25, 2012, at 7:12 AM, Petrie, Glen wrote:
> ... 

Since output-bin and OutputBin are a ship that sailed a long long time ago, I think we should stick with it with the appropriate documentation ("bin" refers to a tray, mailbox, pickup roll, etc.)