Okay, here's another possibly way-off-center point.
First, apparently I seriously misunderstood the (implied) semantics of
the CurrentCharSet and CurrentNaturalLanguage properties. I apologize.
I assumed (always a bad strategy) that they were global items that could
in fact set the default behavior of the management agent. That is,
behavior similar to prtGeneralLocalization, though that does not permit
character set and language to vary independently.
However, I am now really puzzled about a useful interpretation of the
meaning of "Current" in these cases. Two questions. Easy one first.
1. The printer MOF does not specify any read-write access for
properties. The CIM default for this attribute is False. Should we
attempt to correct this? Do we think that these properties might permit
read-write access? Do we think that any properties in CIM_Printer
should permit read-write access? Such a declaration would be for
modeling only; implementations would still get to permit or forbid write
access, authorize it, etc.
2. Do we think that such properties are global to the management agent
or local to a management session? If two users simultaneously request
management information in two different languages (using some protocol
mechanism outside these properties), do they see different values of
CurrentNaturalLanguage? And how current is "Current?" Does the value
returned describe the language in which this particular response message
is written, or does it refer to a global setting in the printer?
I agree with Ira that the printer current values don't change. I would
not expect any such request to alter the value of
CurrentNaturalLanguage. A deliberate SET operation might alter the
value, but only if the property is writable; see question 1.
Is there a useful interpretation that we can agree on (and then record
in text in the new MOF), for the semantics of these properties?
Suggestions:
- A CurrentXxxx property describes the behavior of the management agent
for all management request-response exchanges or sessions, unless the
request that initiates the session specifies different behavior.
- A request that specifies different behavior does not change the value
of the CurrentXxxx property.
- The mechanism used by a request to specify different behavior is
beyond the scope of this MOF.
- A CurrentXxxx property may or may not be settable by the end user, as
part of management policy. The MOF declares that the property as
modeled may be writable. Implementations may vary in their ability to
write the property, or to authorize writing by consumers, and so forth.
Would such semantics be useful to write down? The current MOF doesn't
specify the behavior of these properties very clearly.
If this whole topic is not completely off-base, we could just add it to
the list of non-cosmetic questions.
Sorry for the length.
rick
________________________________
From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Monday, August 08, 2005 22:26
To: McDonald, Ira; 'wamwagner@comcast.net'; Landau, Richard;
wims@pwg.org
Cc: Bumpus, Winston
Subject: RE: WIMS> CIM> Deprecating (almost) all CurrentXxxx properties
in CIM_Printer
Hi,
By the way, the corresponding IPP Printer attributes are called
'charset-configured' and 'natural-language-configured'. Given that
IPP and the Printer MIB frequently refer to the 'current configuration',
DMTF CIM property names of 'Current...' are fine if we deprecate
all the other non-deterministic 'CurrentXxx' properties.
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@sharplabs.com
-----Original Message-----
From: owner-wims@pwg.org [mailto:owner-wims@pwg.org]On Behalf Of
McDonald, Ira
Sent: Monday, August 08, 2005 6:46 PM
To: 'wamwagner@comcast.net'; Richard_Landau@Dell.com;
wims@pwg.org
Cc: Winston_Bumpus@Dell.com
Subject: RE: WIMS> CIM> Deprecating (almost) all CurrentXxxx
properties in CIM_Printer
Hi,
I agree with the proposal.
However, I strongly DISAGREE with the creation of new DefaultXxx
properties to be used in place of
CurrentCharSet/NaturalLanguage.
We had this discussion during the development of IPP and
concluded
that DefaultXxx has the wrong semantics, because they CANNOT be
overridden by the user. They are the character set and language
for the values in the Printer Description class of attributes
(broadly,
everything except Status attributes). A specific user can
request
a Notification (for example) in a different charset/language,
but the
Printer current values don't change. This is NOT the semantics
of DefaultXxx on a Printer object.
Note that the user MUST specify the charset/language of
submitted
string attributes with an IPP Job - it's a protocol error to
omit them.
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@sharplabs.com
-----Original Message-----
From: owner-wims@pwg.org [mailto:owner-wims@pwg.org]On
Behalf Of wamwagner@comcast.net
Sent: Monday, August 08, 2005 3:43 PM
To: Richard_Landau@Dell.com; wims@pwg.org
Cc: Winston_Bumpus@Dell.com
Subject: Re: WIMS> CIM> Deprecating (almost) all
CurrentXxxx properties in CIM_Printer
Rick,
Makes sense. Perhaps we got carried away in our
generalizations and missed the distinction.
I would see no benefit in changing the names of
urrentCharSet or CurrentNaturalLanguage
Bill Wagner
-------------- Original message --------------
Re: Deprecating (almost) all CurrentXxxx
properties in CIM_Printer
Slight revision to the proposal: Deprecate all
the CurrentXxxx properties in favor of the corresponding DefaultXxxx
properties, except CurrentCharSet and CurrentNaturalLanguage.
These last two properties, CharSet and
NaturalLanguage, record the character set and natural language being
used for management, not for printing. They are properties of the
printer controller, not properties of print jobs. Since they are
asynchronous with printing functions, they do not suffer from the
ambiguities of the other CurrentXxxx properties in complex printers.
Also, neither of these properties has a corresponding DefaultXxxx
property. Therefore these two properties must be retained.
Summary:
CurrentPaperType deprecate; use
DefaultPaperType instead
CurrentLanguage deprecate; use
DefaultLanguage
CurrentMimeType deprecate; use
DefaultMimeType
CurrentCapabilities deprecate; use
DefaultCapabilities
CurrentCharSet retain
CurrentNaturalLanguage retain
I recall that some exceptions were mentioned,
but I think we all mistakenly referred to CurrentLanguage instead of
CurrentCharSet during the discussion.
Addendum to proposal: we could change the
*names* of the two remaining CurrentXxxx properties to DefaultCharSet
and DefaultNaturalLanguage and then be rid of all the CurrentXxxx
properties. (Actual process: add new properties with identical syntax
and semantics but new names, and then deprecate the old properties.)
Only half kidding.
Comments, please.
rick
-------------------------
Richard_Landau@dell.com, System Mgt Arch & Stds
+1-512-728-9023, One Dell Way, RR5-3 Box 8352,
Round Rock, TX 78682
This archive was generated by hypermail 2b29 : Tue Aug 09 2005 - 15:28:25 EDT