Hi Ron,
If Apple and others never want to display port/channel
state/status from the Printer MIB, we can throw out
ppmPortChannelIndex. Otherwise, it's a bad mistake.
Only the ppmPortChannelIndex object can be used to
disambiguate which prtChannelState/prtChannelStatus to
use for detailed port status - otherwise, the ppmPortTable
_cannot_ be mapped into the prtChannelTable at all - because
channels frequently do have duplicate protocol types in
existing printers - there's no key.
The prtChannelIndex _does_ disambiguate text versus binary.
The prtChannelTable contains the two key pointer elements:
prtChannelCurrentJobCntlLangIndex
prtChannelDefaultPageDescLangIndex
These point into the prtInterpreterTable and _can_ be used
to disambiguate the mode of the interpreter (and channel)
via the machine-readable objects in prtInterpreterTable and
the prtInterpreterDescription object.
Of course, if we throw out ppmPortDescription, there's still
no fix for the design flaw in prtChannelTable that it lacks
prtChannelDescription.
Keeping it simple doesn't mean adding new design flaws.
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: Bergman, Ron [mailto:Ron.Bergman at rpsa.ricoh.com]
Sent: Monday, April 25, 2005 1:08 PM
To: McDonald, Ira; Mike Fenelon; Paul Danbold
Cc: pmp at pwg.org; Harry Lewis (E-mail); Ivan Pavicevic
Subject: RE: Adding ppmPortDescription to Port Mon MIB
Ira,
One of the goals of this MIB was to keep it light weight and not load it up
with all the normal extras we
put in the MIB to meet all the imposed requirements. In this case it does
not seem to be necessary to
have both a descriptive name and a description. Both Mike and Paul have
agreed. If we follow your
suggestion, the name will end up being a very generic name installed by the
manufacturer and not of
much use to the "port installer" function. The whole purpose of calling
this a descriptive name was to
eliminate the need for the 2 objects. Let's change the object name to
reflect this change to
"ppmPortDescrName" so it doesn't violate are "rules".
Also, the need to restore "ppmPortChannelIndex" based upon its ability "to
disambiguate (for example)
Text vs Binary LPR channels" is incorrect. The Channel Table does not
provide any information regarding
Text vs Binary.
Ron
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Saturday, April 23, 2005 2:32 PM
To: Bergman, Ron; Mike Fenelon; McDonald, Ira; Paul Danbold
Cc: pmp at pwg.org; Harry Lewis (E-mail); Ivan Pavicevic
Subject: RE: Adding ppmPortDescription to Port Mon MIB
Hi,
Forgive the delay in response - I was offline packing for two days.
There's a PWG Semantic Model naming convention for elements here
that's important (and agrees with Mike's intended usage).
In the Semantic Model (and in IPP) there are two distinct base datatypes:
Name (restricted character set, leaving out most non-alpha/non-digit) and
Text (unrestricted character set, except that most control characters are
still invalid).
In Printer MIB, Job MIB, SM/1.0, and IPP there are numerous elements
that are called 'XxxName' (e.g., prtInputName in the Printer MIB) that are
_static_ and SHOULD NOT be changed (or lost across reboots) after
device installation (when the Administrator can override the Factory default
name). Such elements are used in SM/1.0 as _keys_ (for object lookup).
In Printer MIB, etcm there are also numerous elements that are called
'XxxDescription' (e.g., prtInputDescription) that are _dynamic_ and SHOULD
be changed when the current configuration of the element is modified
by an Operator or Administrator. Such elements are never used as keys.
An element called (or used) ppmPortNameOrDescription _cannot_ be added
to the Semantic Model (because it breaks existing strong typing in our XML
schema).
The Apple request can only be satisfied by a separate, dynamic text object.
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: Bergman, Ron [mailto:Ron.Bergman at rpsa.ricoh.com]
Sent: Thursday, April 21, 2005 3:24 PM
To: Mike Fenelon; McDonald, Ira; Paul Danbold
Cc: pmp at pwg.org; Harry Lewis (E-mail); Ivan Pavicevic
Subject: RE: Adding ppmPortDescription to Port Mon MIB
Mike,
The ppmPortName object may contain a maximum of 127 characters.
Does this meet your requirement?
Ron
-----Original Message-----
From: Mike Fenelon [mailto:mfenelon at windows.microsoft.com]
Sent: Thursday, April 21, 2005 9:59 AM
To: Bergman, Ron; McDonald, Ira; Paul Danbold
Cc: pmp at pwg.org; Harry Lewis (E-mail); Ivan Pavicevic
Subject: RE: Adding ppmPortDescription to Port Mon MIB
The intent of this object is to give a short, concise user-friendly name of
the port. It will be presented in the User Interface for and device that
advertises more than one port so the user can pick the correct port for
their connected printer. The whole intent was to differentiate between
multiple ports on a device that could host multiple printers. I am
concerned we will start degrading the user experience if we add a whole
bunch of ports for the same printer with slightly different names.
Mike Fenelon
Microsoft
From: Bergman, Ron [mailto:Ron.Bergman at rpsa.ricoh.com]
Sent: Thursday, April 21, 2005 9:32 AM
To: McDonald, Ira; Paul Danbold
Cc: pmp at pwg.org; Harry Lewis (E-mail); Mike Fenelon; Ivan Pavicevic
Subject: RE: Adding ppmPortDescription to Port Mon MIB
Ira,
I would like to hear from Mike or Ivan on this subject, rather than rely on
memory.
Your comment does not agree with the current description clause for this
object.
Ron
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Thursday, April 21, 2005 8:37 AM
To: 'Paul Danbold'; Bergman, Ron
Cc: pmp at pwg.org; Harry Lewis (E-mail); McDonald, Ira;
MFenelon at microsoft.com; IvanP at microsoft.com
Subject: RE: Adding ppmPortDescription to Port Mon MIB
Hi Ron,
Doesn't work - MS specifically said that they wanted PortName restricted
to a _name_ that they will display in their tools and do NOT want it to
include descriptive text. Your memory is incorrect.
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: Paul Danbold [mailto:danbold at apple.com]
Sent: Wednesday, April 20, 2005 11:55 PM
To: Bergman, Ron
Cc: pmp at pwg.org; Harry Lewis (E-mail); Ira McDonald (E-mail 3);
MFenelon at microsoft.com; IvanP at microsoft.com
Subject: Re: Adding ppmPortDescription to Port Mon MIB
Ron,
Thanks for the clarification. In the expectation that manufacturers will
initialize ppmPortName with helpful information, I am satisfied there is no
need to add an additional object.
-Paul
---------------------------------------------------------------
Paul Danbold
Imaging Technologies Evangelist, Apple Worldwide Developer Relations
3 Infinite Loop, MS:303-2TE, Cupertino, CA 95014
408-974-0050 (office) 408-425-3351 (mobile)
---------------------------------------------------------------
On Apr 15, 2005, at 9:48 AM, Bergman, Ron wrote:
I remembered this morning why we decided, several months back, to remove
this object.
Since the MIB contained both a desciptive name and a description, it was
agreed that
the two objects were redundant. To clarify this situation I recommend that
the object
ppmPortName be changed to ppmPortDescriptiveName or ppmPortDescription,
rather
than go back to the original redundant pair.
ppPortName is a natural language string with up to 127 characters. For Paul
Danbold's
example I could provide a name such as:
"Networked LPR port providing binary PostScript printing for use by
marketing"
This is less than 80 characters and should be more than sufficient to
satisfy Paul's
requirement.
Also, in addition to a possible name change, it must be noted that this
object is
expected to be administratively configured using an out-of-band method.
Paul, please indicate if this is sufficient.
Ron Bergman
Ricoh Printing Systems America