Hi Stuart,
Comments inline below.
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 8:30 PM
To: McDonald, Ira; wamwagner at comcast.net
Cc: wims at pwg.org
Subject: RE: WIMS> RE: Counter MIB questions
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.
<ira>
IPP does this weakly with the fuzzy "media" attribute and strongly
(supposedly) with the "media-key" attribute in the "media-col", so
those are the normative sources for the existing PWG Semantic Model/1.0
in the XML schema.
</ira>
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.
<ira>
During the development of the Abstract Counter spec (PWG 5106.1), there
was strong concensus that the list of MediaUsed must have a unique key
(other than the ephemeral "MediaUsedIndex" in the Counter MIB mapping).
Sorry my example wasn't more complete - I agree that weight, tooth, etc.,
might also be needed in some cases - note that there is no possible
_interoperability_ across printer manufacturers and fleet management
application vendors, because the choice and order of all of these
possible distinguishing characteristics has not been standardized.
But an accounting application in a given enterprise working with a
given manufacturer's printer would want to correlate specific media
with that used in another printer from the same manufacturer (at a
minimum). A hard problem that got swept under the table during the
Abstract Counter spec development. Many of these media characteristics
are only currently standardized (and enumerated) in CIP4 JDF and the
FSG/OP Job Ticket API standards.
A really _opaque_ key (e.g., a UUID) is a possibility, but neither
humans nor machines could make any reasonable correlations.
Since Pete Zehler has already added the MediaUsed counters to the
Counters schema that is Semantic Model/2.0 work-in-progress, this
issue has some urgency, I think.
</ira>
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
--
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