WIMS> RE: Counter MIB questions

WIMS> RE: Counter MIB questions

WIMS> RE: Counter MIB questions

Stuart Rowley Stuart.Rowley at ktd-kyocera.com
Mon Jul 10 20:30:27 EDT 2006


Hi Ira and Bill,

 

I would like to back track from my previous statement that a unique
media key seems necessary. Instead I would like to restate the
problem(s). 

 

1) Print jobs need to be able to uniquely or at least unambiguously
identify the size and type of media that should be used.

2) Accounting applications need to categorize the size and types of
media used for billing purposes.

 

I'm not sure "unique" is achievable. You listed color/type/coating, but
customers could also want to specify just about any media type
attribute: weight, grain, brightness, manufacturer, content (5% fair
trade hand picked hemp fibers).... so rather than unique, it seems we
have to decide the level to go to.

 

Accounting applications probably do not normally need this same level of
definition. Indeed most of our devices use just standard types such as
bond, letterhead, transparency, etc. as well as a few customizable
types. Thus, from an accounting standpoint, anything other than the
standard types is custom. So for accounting it is sufficient (and maybe
more desirable) to say "bond" rather than
"white-bond-matte-24lb-89brightness".

 

Another question I have is if the size is identified in ...SizeName, why
should it also be included in the media key? 

 

Thanks,

 

Stuart

 

Stuart Rowley

Kyocera Technology Development

 

________________________________

From: McDonald, Ira [mailto:imcdonald at sharplabs.com] 
Sent: Monday, July 10, 2006 1:34 PM
To: Stuart Rowley; wamwagner at comcast.net
Cc: wims at pwg.org
Subject: RE: WIMS> RE: Counter MIB questions

 

Hi Stuart,

 

The attribute media-key (in media-col) is meant to be a unique key.

Description of the attribute's value in PWG 5100.3 is underspecified.

 

I suggest we should require using hyphen-separated media descriptive 

keywords (size, color, type) from PWG 5101.1 (Standard Media Names)

followed by a free-form suffix based on media weight, coating, etc.

(taken from the other attributes in media-col in PWG 5100.3).

 

For example,

 

iso-a4-white-stationery-satin (size/color/type/front coating)

 

Comments?

 

Cheers,

- Ira

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 

	-----Original Message-----
	From: Stuart Rowley [mailto:Stuart.Rowley at ktd-kyocera.com]
	Sent: Monday, July 10, 2006 11:22 AM
	To: McDonald, Ira; wamwagner at comcast.net
	Cc: wims at pwg.org
	Subject: RE: WIMS> RE: Counter MIB questions

	Bill and Ira,

	 

	A unique media key seems necessary to me. I have looked at
5100.3, and it seems it would take careful study for me to understand
the implementation of media key in this document. I just didn't get it
in a quick pass.

	 

	Thanks,

	 

	Stuart

	 

	Stuart Rowley

	Kyocera Technology Development

	 

	
________________________________


	From: lynnewagner at comcast.net [mailto:lynnewagner at comcast.net] 
	Sent: Sunday, July 09, 2006 7:03 PM
	To: McDonald, Ira; 'wamwagner at comcast.net'; Stuart Rowley
	Cc: wims at pwg.org
	Subject: RE: WIMS> RE: Counter MIB questions

	 

	Hello Ira,

	 

	Yes, that sounds good. Do we have any comments from the list?

	 

	Bill Wagner

	 

	--
	A. Lynne Wagner, EdD, MSN, RN 
	Consultant, Nurse Career and Mentor Coach 
	Phone: 978-764-3982 
	E-Mail: lynnewagner at comcast.net 

	 

		-------------- Original message -------------- 
		From: "McDonald, Ira" <imcdonald at sharplabs.com> 

		Hi Bill,

		 

		The best solution would be to lead '...MediaInfo' as
descriptive and

		add a new attribute '...MediaKey' (see PWG 5100.3) that
IS unique.

		 

		This wants some consideration and discussion.

		 

		Cheers,

		- Ira

		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 

			-----Original Message-----
			From: wamwagner at comcast.net
[mailto:wamwagner at comcast.net]
			Sent: Friday, July 07, 2006 12:34 PM
			To: McDonald, Ira; 'Stuart Rowley'
			Cc: wims at pwg.org
			Subject: RE: WIMS> RE: Counter MIB questions

			Ira,

			 

			Understood. That is a problem with not
prototyping, although there is no guarentee that all issues will be
found  when prototyping. So, pending further discoveries, perhaps we
should consider an errata to the counter spec? I take it that we would
add another object, with 'icMediaUsedMediaInfo' being redefined and
retyped as a media qualifier and (perhaps) ''icMediaUsedMediaDescrip"
being added for user infomation?

			 

			Bill Wagner

			 

				-------------- Original message
-------------- 
				From: "McDonald, Ira"
<imcdonald at sharplabs.com> 

				Hi Bill,

				 

				I agree that 'icMediaUsedMediaInfo' is
overloaded with two probably

				incompatible uses, but it isn't the MIB
that did this overloading.  This

				is a bug in the PWG Candidate Standard
Imaging System Counters

				(PWG 5106.1) - see section 5.3 on the
bottom of page 27.

				 

				This bug cannot be fixed in the MIB
independently, without revision 

				of the source document's element
semantics.

				 

				Cheers,

				- Ira

				 

				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 

				-----Original Message-----
				From: wamwagner at comcast.net
[mailto:wamwagner at comcast.net]
				Sent: Thursday, July 06, 2006 4:36 PM
				To: McDonald, Ira; 'Stuart Rowley'
				Cc: wims at pwg.org
				Subject: Re: WIMS> RE: Counter MIB
questions

				OK. Ira, it seems that you agree with
Stuart that: 

				icMediaUsedMediaSizeName DisplayString
and

				icMediaUsedMediaInfo SnmpAdminString

				both are not localized. 

				 

				The former is a PWG 5101.1 defined
keyword; the latter is freeform in that it is not a public-spec defined
keyword, but operationally should be one of a set of strings defined for
use in a particular environment or with  a particular application.

				 

				This appears to overload
icMediaUsedMediaInfo as both a qualifying descriptor for media
identification and as a description for human consumption.

				 

				Since the MIB is informational only
(pending prototyping), and Stuart may be doing the prototyping, I would
suggest that we collect the issues discovered during this effort and
define an updated version of the MIB for resubmission as a candidate
standard. 

				 

				Bill Wagner

				 

				-------------- Original message
-------------- 
				From: "McDonald, Ira"
<imcdonald at sharplabs.com> 

				Hi Stuart,

				 

				The ASCII keyword in '...SizeName'
should NOT be localized, 

				but the equivalent elements in
'...MediaInfo' ARE supposed to 

				be localized.

				 

				But, because '...MediaInfo' in the
Abstact Counter spec (PWG 

				5106.1) and Counter MIB is required for
the key distinguishing 

				two instances of the same size media
(e.g., by color), it's highly

				undesirable to change the value of
'...MediaInfo' when the printer

				locale changes -  lousy side effects for
accounting applications.

				 

				Bill - I consider this a probable errata
against the Counter MIB.

				 

				Cheers,

				- Ira

				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 

				-----Original Message-----
				From: Stuart Rowley
[mailto:Stuart.Rowley at ktd-kyocera.com]
				Sent: Wednesday, July 05, 2006 9:07 PM
				To: McDonald, Ira
				Cc: wims at pwg.org
				Subject: RE: Counter MIB questions

				Hi Ira,

				 

				Thanks for the quick reply. 

				 

				The description for
icMediaUsedMediaSizeName says:

				 

				"The media size self-describing name for
this specific media,

				for use with remote network management
scripts and GUIs,

				specified as a Unicode string encoded in
UTF-8 (RFC 3629)

				in the language specified in
'icGeneralNaturalLanguage'.

				 

				...so would this ASCII keyword be
localized...?

				 

				Thanks,

				 

				Stuart

				
________________________________


				From: McDonald, Ira
[mailto:imcdonald at sharplabs.com] 
				Sent: Wednesday, July 05, 2006 12:47 PM
				To: Stuart Rowley; McDonald, Ira
				Cc: 'wims at pwg.org'
				Subject: RE: Counter MIB questions

				 

				Hi Stuart,

				 

				I copied the WIMS list, so others could
see my remarks and chime in.

				 

				The significance of
icMediaUsedMediaSizeName being DisplayString is

				that it MUST be strict ASCII (it's a
_keyword_ that follows the format in

				PWG 5101.1, not a free form name - even
a custom size name has a

				format and MUST be strict ASCII).

				 

				icMediaUsedMediaInfo is a description
that makes '...SizeName' unique for 

				instances of different (but same size)
media.  Because the IETF leaned

				on us hard to make all future MIB
descriptive strings be internationalized,

				it's of type SnmpAdminString (UTF-8) and
localized.

				 

				Now - nothing prevents you from making
the "localized" media info in

				Kyocera products be of the form:

				 

				  media-info = english-media-identifier
":" localized-description

				 

				So that your accounting applications use
the invariant identifier and

				save the localized-description (if at
all) in a separate database field

				that's informational.

				 

				Or you could cheat (I don't recommend
this) and leave the value of

				icGeneralNaturalLanguage empty and just
support all descriptive

				fields in US-English only (the default)
- I _really_ don't recommend

				this approach, because it's not very
customer-friendly.

				 

				Hope this helps,

				- Ira

				 

				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 

				-----Original Message-----
				From: Stuart Rowley
[mailto:Stuart.Rowley at ktd-kyocera.com]
				Sent: Wednesday, July 05, 2006 1:47 PM
				To: McDonald, Ira
				Subject: Counters MIB questions

				Hi Ira,

				 

				I hope you had an enjoyable 4th of July
weekend. 

				 

				I have a couple questions about the
Counters spec and MIB regarding media used.

				 

				There are 3 objects used to describe the
media size and type.

				icMediaUsedMediaSizeName DisplayString,

				icMediaUsedMediaInfo SnmpAdminString,

				icMediaUsedMediaName SnmpAdminString

				 

				What is the significance of
icMediaUsedMediaSizeName using DisplayString and the others using
SnmpAdminString?

				 

				In the MIB it lists all three as being
localized, but it seems only icMediaUsedMediaName should be localized. I
need icMediaUsedMediaSizeName and icMediaUsedMediaInfo to be used by our
accounting apps to identify the size and type for billing purposes. This
would be hard to achieve using localized strings. Our apps would need to
read standardized names from these two objects. Am I missing something?

				 

				Thanks,

				 

				Stuart

				 

				Stuart Rowley

				Network Product Mgr.

				Kyocera Technology Development

				 

				--
				No virus found in this outgoing message.
				Checked by AVG Free Edition.
				Version: 7.1.394 / Virus Database:
268.9.9/382 - Release Date: 7/4/2006

				 

				--
				No virus found in this outgoing message.
				Checked by AVG Free Edition.
				Version: 7.1.394 / Virus Database:
268.9.9/382 - Release Date: 7/4/2006

				 

				--
				No virus found in this outgoing message.
				Checked by AVG Free Edition.
				Version: 7.1.394 / Virus Database:
268.9.9/382 - Release Date: 7/4/2006

		 

		--
		No virus found in this outgoing message.
		Checked by AVG Free Edition.
		Version: 7.1.394 / Virus Database: 268.9.10/383 -
Release Date: 7/7/2006


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.10/384 - Release Date:
7/10/2006


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20060710/75640d58/attachment.html


More information about the Wims mailing list